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REMARKS 

Claims 28-50 are pending. Applicant has amended claims 28, 29, 36, and 44. 

Applicant thanks the Examiner for his consideration during the interview conducted 
on July 6, 2007. During the interview, applicant's representative discussed amendments, 
made herein, that the Examiner indicated would distinguish the claims over the reference 
Stapel. 

The Examiner rejected claims 28-50 under 35 U.S.C. § 103(a) over Stapel 
(6,912,538). Applicant respectfully traverses this rejection. 

Stapel describes a matrix traversal representation of a document type definition. An 
XML Document Type Definition (DTD) defines the types of elements that can appear in a 
document and a permitted set of relationships between document elements. For example, 
the DTD may define that a document can have elements of type A, B, and C, and that an 
element of type A can have child elements of type B or C, but not any other types. Stapel, 
col. 5:39-41, 8:52-57. Stapel converts the DTD schema into a set of tables, called a matrix 
representation, which is algorithmically easier to use for validating documents than the 
original DTD. Stapel, col. 6:66-7:12. A DTD only contains information about data types, 
not the instances of those types found in a document. Thus, Stapel does not address 
relationships between instances of data in a document 

In contrast, applicant's technology converts a hierarchical model of data in a 
document (e.g., XML) to a new representation of the data, called the item, relation, 
attribute (IRA) model. Hierarchical models, such as XML, represent hierarchical 
relationships explicitly, such as by nesting elements. A difficulty with such hierarchical 
models is that there is no support for explicitly representing non-hierarchical relationships. 
For example, if the document contains a family tree in which children are in elements 
nested below their parents (a hierarchical parent-child relationship), then there is no 
explicit way to represent a relationship between two people in the tree that are friends (a 
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non-hierarchical relationship). As a result, creators of documents adhering to a 
hierarchical model use various implicit mechanisms to represent non-hierarchical 
relationships. These mechanisms often involve repeating the data in each place where the 
entity referred to by the data has a relationship with another entity. For example, in the 
family tree, a friend element can be created below each of the two friends that repeats the 
other persons name. Repeating data causes difficulty when validating the document and 
making changes to the document, because many instances of the same data may need to 
be located and changed. 

The following XML illustrates the family tree example above. 

<People> 

<Person Name="Albert"/> 

<Person Name="Bob"> 
<Person Name="chris"/> 
<Person Name="Don"> 

<Fn'end Name="Bob"> 

</People> 

In the above XML, a person Albert has a child named Bob, and a person named 
Chris has a child named Don. The parent-child relationship is explicit through the nesting 
of elements: the person element for Bob is a child of the person element for Albert. Don 
and Bob are friends. To represent this relationship, a new element type Friend is 
introduced and nested under the element Don. Notice that the person Bob now appears in 
two different places. There is only one entity Bob, but there are references to Bob 
throughout the XML. As the XML grows more complex, the repetition of data becomes 
more difficult to deal with. 

Each of applicant's claims recites "wherein the current representation represents 
some relationships between entities hierarchically by nesting elements and other 
relationships non-hierarchically by referring to another element of the hierarchical model, 
such that the current representation contains multiple references to at least one entity," 
and "wherein only one item is created in the new representation for the at least one entity 
having multiple references in the current representation." Stapel does not teach or 
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suggest converting a current representation of a document having multiple references to 
an entity to a new representation of the document that represents each entity with a single 
item. Stapel is primarily focused on a DTD and a DTD only contains information about 
data types, not data itself. Thus, Stapel does not describe repeated data and, in particular, 
any way of creating a new representation that does not repeat data. 

In addition, even if the data types of Stapel can be treated the same as applicant's 
data (with which applicant disagrees), Stapel does not teach or suggest any way of 
removing repeated data types in the matrix representation that Stapel creates. As shown 
in Figure 1 of Stapel, the DTD may have more than one element describing data type X 
and more than one element describing data type A in the matrix representation. Stapel 
distinguishes the two nodes by the path used to reach them, "[t]he methods for defining the 
structured document presented herein overcome this problem and enable different values 
to be assigned to the element X depending on the path taken to reach the element." 
Stapel, col. 6:51-54. In contrast, applicant's technology identifies multiple references to an 
entity in the input representation and replaces them with a single item in the new 
representation. Figure 2 of applicant's specification provides an example. The XML 
representation on the right contains two references to Mary, whereas the new 
representation on the left contains a single item Mary. Therefore, applicant's claims are 
patentable over Stapel. Accordingly, applicant respectfully requests that these rejections 
be withdrawn. 

Based upon these remarks and amendments, Applicants respectfully request 
reconsideration of this application and its early allowance. If the Examiner has any 
questions or believes a telephone conference would expedite prosecution of this 
application, the Examiner is encouraged to call the undersigned at (206) 359-3265. 
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Applicants believe all required fees are being paid in connection with this response. 
However, if an additional fee is due, please charge our Deposit Account No. 50-0665, 
under Order No. 418268851 US from which the undersigned is authorized to draw. 




P.O. Box 1247 

Seattle, Washington 98111-1247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorneys for Applicant 
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